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Abstract 


Multipath TCP (MPTCP for short) describes the extensions proposed for 
TCP so that endpoints of a given TCP connection can use multiple 
paths to exchange data. Such extensions enable the exchange of 
segments using different source-destination address pairs, resulting 
in the capability of using multiple paths in a significant number of 
scenarios. Some level of multihoming and mobility support can be 
achieved through these extensions. However, the support for multiple 
IP addresses per endpoint may have implications on the security of 
the resulting MPTCP. This note includes a threat analysis for MPTCP. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6181. 
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1. Introduction 


Multipath TCP (MPTCP for short) describes the extensions proposed for 
TCP [RFC0O793] so that endpoints of a given TCP connection can use 
multiple paths to exchange data. Such extensions enable the exchange 
of segments using different source-destination address pairs, 
resulting in the capability of using multiple paths in a significant 
number of scenarios. Some level of multihoming and mobility support 
can be achieved through these extensions. However, the support for 
multiple IP addresses per endpoint may have implications on the 
security of the resulting MPTCP. This note includes a threat 
analysis for MPTCP. There are many other ways to provide multiple 
paths for a TCP connection other than the usage of multiple 
addresses. The threat analysis performed in this document is limited 
to the specific case of using multiple addresses per endpoint. 


2. Scope 


There are multiple ways to achieve Multipath TCP. Essentially, what 
is needed is for different segments of the communication to be 
forwarded through different paths by enabling the sender to specify 
some form of path selector. There are multiple options for such a 
path selector, including the usage of different next hops, using 
tunnels to different egress points, and so on. The scope of the 
analysis included in this note is limited to a particular approach, 
namely MPTCP, that relies on the usage of multiple IP address per 
endpoint and that uses different source-destination address pairs as 
a means to express different paths. So, in the rest of this note, 
the MPTCP expression will refer to this multi-addressed flavor of 
Multipath TCP [MPTCP-MULTIADDRESSED]. 


This goal of this note is to perform a threat analysis for MPTCP. 
Introducing the support of multiple addresses per endpoint ina 
single TCP connection may result in additional vulnerabilities 
compared to single-path TCP. The scope of this note is to identify 
and characterize these new vulnerabilities. So, the scope of the 
analysis is limited to the additional vulnerabilities resulting from 
the multi-address support compared to the current TCP (where each 
endpoint only has one address available for use per connection). A 
full analysis of the complete set of threats is explicitly out of the 
scope. The goal of this analysis is to help the MPTCP designers 
create an MPTCP specification that is as secure as the current TCP. 
It is a non-goal of this analysis to help in the design of MPTCP that 
is more secure than regular TCP. 


The focus of the analysis is on attackers that are not along the 


path, at least not during the whole duration of the connection. In 
the current single-path TCP, an on-path attacker can launch a 
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significant number of attacks, including eavesdropping, connection 
hijacking Man-in-the-Middle (MiTM) attacks, and so on. However, it 
is not possible for the off-path attackers to launch such attacks. 
There is a middle ground in case the attacker is located along the 
path for a short period of time to launch the attack and then moves 
away, but the attack effects still apply. These are the so-called 
time-shifted attacks. Since these are not possible in today’s TCP, 
they are also consider in the analysis. So, summarizing, both 
attacks launched by off-path attackers and time-shifted attacks are 
considered to be within scope. Attacks launched by on-path attackers 
are out of scope, since they also apply to current single-path TCP. 


However, that some current on-path attacks may become more difficult 
with Multipath TCP, since an attacker (on a single path) will not 
have visibility of the complete data stream. 


3. Related Work 


There is a significant amount of previous work in terms of analysis 
of protocols that support address agility. The most relevant ones 
are presented in this section. 


Most of the problems related to address agility have been deeply 
analyzed and understood in the context of Route Optimization support 
in Mobile IPv6é (MIPv6 RO) [RFC3775]. [RFC4225] includes the 
rationale for the design of the security of MIPv6 RO. All the 
attacks described in the aforementioned analysis apply here and are 
an excellent basis for our own analysis. The main differences are as 
follows: 


o In MIPv6 RO, the address binding affects all the communications 
involving an address, while in the MPTCP case, a single connection 
is at stake. If a binding between two addresses is created at the 
IP layer, this binding can and will affect all the connections 
that involve those addresses. However, in MPTCP, if an additional 
address is added to an ongoing TCP connection, the additional 
address will/can only affect the connection at hand and not other 
connections, even if the same address is being used for those 
other connections. The result is that, in MPTCP, there is much 
less at stake and the resulting vulnerabilities are less. On the 
other hand, it is very important to keep the assumption valid that 
the address bindings for a given connection do not affect other 
connections. If reusing of binding or security information is to 
be considered, this assumption could be no longer valid and the 
full impact of the vulnerabilities must be assessed. 
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o In MIPv6, there is a trusted third party, called the Home Agent 
that can help with some security problems, as expanded in the next 
bullet. 


o In MIPv6 RO, there is the assumption that the original address 
(Home Address) through which the connection has been established 
is always available, and in case it is not, the communication will 
be lost. This is achieved by leveraging in the on the trusted 
party (the Home Agent) to relay the packets to the current 
location of the Mobile Node. In MPTCP, it is an explicit goal to 
provide communication resilience when one of the address pairs is 
no longer usable, so it is not possible to leverage on the 
original address pair to be always working. 


o MIPv6 RO is, of course, designed for IPv6, and it is an explicit 
goal of MPTCP to support both IPv6 and IPv4. Some MIPv6 RO 
security solutions rely on the usage of some characteristics of 
IPv6 (such as the usage of Cryptographically Generated Addresses 
(CGA) [RFC3972]), which will not be usable in the context of 
MPTCP. 


o As opposed to MPTCP, MIPv6 RO does not have connection-state- 
information, including sequence numbers, port numbers that could 
be leveraged to provide security in some form. 


In the Shim6 [RFC5533] design, similar issues related to address 
agility were considered and a threat analysis was also performed 
[RFC4218]. The analysis performed for Shim6 also largely applies to 
the MPTCP context, the main differences being: 


O The Shim6 protocol is a layer 3 protocol so all the communications 
involving the target address are at stake; in MPTCP, the impact 
can be limited to a single TCP connection. 


o Similar to MIPv6 RO, Shim6 only uses IPv6 addresses as identifiers 
and leverages on some of their properties to provide the security, 
such as relying on CGA or Hash-Based Addresses (HBA) [RFC5535], 
which is not possible in the MPTCP case where IPv4 addresses must 
be supported. 


o Similar to MIPv6 RO, Shim6 does not have a connection-state- 
information, including sequence numbers, port that could be 
leveraged to provide security in some form. 


Stream Control Transmission Protocol (SCTP) [RFC4960]is a transport 
protocol that supports multiple addresses per endpoint and the 
security implications are very close to the ones of MPTCP. A 
security analysis, identifying a set of attacks and proposed 
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solutions was performed in [RFC5062]. The results of this analysis 
apply directly to the case of MPTCP. However, the analysis was 
performed after the base SCTP was designed and the goal of the 
document was essentially to improve the security of SCTP. As such, 
the document is very specific to the actual SCTP specification and 
relies on the SCTP messages and behavior to characterize the issues. 
While some them can be translated to the MPTCP case, some may be 
caused by the specific behavior of SCTP. 


So, the conclusion is that while there is significant amount of 
previous work that is closely related, and it can and will be used it 
as a basis for this analysis, there is a set of characteristics that 
are specific to MPTCP that grant the need for a specific analysis for 
MPTCP. The goal of this analysis is to help MPTCP designers to 
include a set of security mechanisms that prevent the introduction of 
new vulnerabilities to the Internet due to the adoption of MPTCP. 


4. Basic MPTCP 


The goal of this document is to serve as input for MPTCP designers to 
properly take into account the security issues. As such, the 
analysis cannot be performed for a specific MPTCP specification, but 
must be a general analysis that applies to the widest possible set of 
MPTCP designs. In order to do that, the fundamental features that 
any MPTCP must provide are identified and only those are assumed 
while performing the security analysis. In some cases, there is a 
design choice that significantly influences the security aspects of 
the resulting protocol. In that case, both options are considered. 


It is assumed that any MPTCP will behave in the case of a single 
address per endpoint as TCP. This means that an MPTCP connection 
will be established by using the TCP 3-way handshake and will use a 
single address pair. 


The addresses used for the establishment of the connection do have a 
special role in the sense that this is the address used as identifier 
by the upper layers. The address used as destination address in the 
SYN packet is the address that the application is using to identify 
the peer and has been obtained either through the DNS (with or 
without DNS Security (DNSSEC) validation) or passed by a referral or 
manually introduced by the user. As such, the initiator does have a 
certain amount of trust in the fact that it is establishing a 
communication with that particular address. If due to MPTCP, packets 
end up being delivered to an alternative address, the trust that the 
initiator has placed on that address would be deceived. In any case, 
the adoption of MPTCP necessitates a slight evolution of the 
traditional TCP trust model, in that the initiator is additionally 
trusting the peer to provide additional addresses that it will trust 
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to the same degree as the original pair. An application or 
implementation that cannot trust the peer in this way should not make 
use of multiple paths. 


During the 3-way handshake, the sequence number will be synchronized 
for both ends, as in regular TCP. It is assumed that an MPTCP 
connection will use a single sequence number for the data, even if 
the data is exchanged through different paths, as MPTCP provides an 
in-order delivery service of bytes 


Once the connection is established, the MPTCP extensions can be used 
to add addresses for each of the endpoints. This is achieved by each 
end sending a control message containing the additional address(es). 
In order to associate the additional address to an ongoing 
connection, the connection needs to be identified. It is assumed 
that the connection can be identified by the 4-tuple of source 
address, source port, destination address, destination port used for 
the establishment of the connection. So, at least, the control 
message that will convey the additional address information can also 
contain the 4-tuple in order to inform about what connection the 
address belong to (if no other connection identifier is defined). 
There are two different ways to convey address information: 


o Explicit mode: the control message contain a list of addresses. 


o Implicit mode: the address added is the one included in the source 
address field of the IP header 


These two modes have different security properties for some type of 
attacks. The explicit mode seems to be the more vulnerable to abuse. 
The implicit mode may benefit from forms of ingress filtering 
security, which would reduce the possibility of an attacker to add 
any arbitrary address to an ongoing connection. However, ingress 
filtering deployment is far from universal, and it is unwise to rely 
on it as a basis for the protection of MPTCP. 


Further consideration regarding the interaction between ingress 
filtering and implicit mode signaling is needed in the case that an 
address that is no longer available from the MPTCP connection is 
removed. A host attached to a network that performs ingress 
filtering and using implicit signaling would not be able to remove an 
address that is no longer available (either because of a failure or 
due to a mobility event) from an ongoing MPTCP connection. 


It is assumed that MPTCP will use all the address pairs that it has 


available for sending packets, and that it will distribute the load 
based on congestion among the different paths. 
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5. Flooding Attacks 


The first type of attacks that are introduced by address agility are 
the flooding (or bombing) attacks. The setup for this attack is 
depicted in the following figure: 


+-------- + (step 1) tas = aes + 
|Attacker | E SaaS SaaS aS | Source | 
| A |IPA IPs| s | 
+-------- + /+------ + 
/ 
(step 2) / 
/ 
v IPT 
+------ + 
Target 
T 
+------ + 


The scenario consists of an Attacker A who has an IP address IPA. A 
server that can generate a significant amount of traffic (such as a 
streaming server), called source S and that has IP address IPS. 
Target T has an IP address IPT. 


In step 1 of this attack, the Attacker A establishes an MPTCP 
connection with the source of the traffic server S and starts 
downloading a significant amount of traffic. The initial connection 
only involves one IP address per endpoint, IPA and IPS. Once the 
download is on course, in step 2 of the attack, the Attacker A adds 
IPT as one of the available addresses for the communication. How the 
additional address is added depends on the MPTCP address management 
mode. In explicit address management, the Attacker A only needs to 
send a signaling packet conveying address IPT. In implicit mode, the 
Attacker A would need to send a packet with IPT as the source 
address. Depending on whether ingress filtering is deployed and the 
location of the attacker, it may or may not be possible for the 
attacker to send such a packet. At this stage, the MPTCP connection 
still has a single address for the Source S, i.e., IPS, but has two 
addresses for the Attacker A, IPA, and IPT. The attacker now 
attempts to get the Source S to send the traffic of the ongoing 
download to the Target T IP address, i.e., IPT. The attacker can do 
that by pretending that the path between IPA and IPT is congested but 
that the path between IPS and IPT is not. In order to do that, it 
needs to send ACKs for the data that flows through the path between 
IPS and IPT and not send ACKs for the data that is sent to IPA. The 
details of this will depend on how the data sent through the 
different paths is ACKed. One possibility is that ACKs for the data 
sent using a given address pair should come in packets containing the 
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same address pair. If so, the attacker would need to send ACKs using 
packets containing IPT as the source address to keep the attack 
flowing. This may or may not be possible depending on the deployment 
of ingress filtering and the location of the attacker. The attacker 
would also need to guess the sequence number of the data being sent 
to the Target. Once the attacker manages to perform these actions, 
the attack is on place and the download will hit the target. In this 
type of attack, the Source S still thinks it is sending packets to 
the Attacker A while in reality it is sending the packet to Target T. 


Once the traffic from the Source S start hitting the Target T, the 
target will react. Since the packets are likely to belong to a non- 
existent TCP connection, the Target T will issue RST packets. It is 
relevant to understand how MPTCP reacts to incoming RST packets. It 
seems that the at least the MPTCP that receives a RST packet should 
terminate the packet exchange corresponding to the particular address 
pair (maybe not the complete MPTCP connection, but at least it should 
not send more packets with the address pair involved in the RST 
packet). However, if the attacker, before redirecting the traffic 
has managed to increase the window size considerably, the flight size 
could be enough to impose a significant amount of traffic to the 
Target node. There is a subtle operation that the attacker needs to 
achieve in order to launch a significant attack. On the one hand, it 
needs to grow the window enough so that the flight size is big enough 
to cause enough effect; on the other hand, the attacker needs to be 
able to simulate congestion on the IPA-IPS path so that traffic is 
actually redirected to the alternative path without significantly 
reducing the window. This will heavily depend on how the coupling of 
the windows between the different paths works, in particular how the 
windows are increased. Some designs of the congestion control window 
coupling could render this attack ineffective. If the MPTCP requires 
performing slow start per subflow, then the flooding will be limited 
by the slow-start initial window size. 


Previous protocols, such as MIPv6 RO and SCTP, that have to deal with 
this type of attacks have done so by adding a reachability check 
before actually sending data to a new address. The solution used in 
other protocols would include the Source S to explicitly asking the 
host sitting in the new address (the Target T sitting in IPT) whether 
it is willing to accept packets from the MPTCP connection identified 
by the 4-tuple IPA, port A, IPS, port S. Since this is not part of 
the established connection that Target T has, T would not accept the 
request and Source S would not use IPT to send packets for this MPTCP 
connection. Usually, the request also includes a nonce that cannot 
be guessed by the Attacker A so that it cannot fake the reply to the 
request easily. In the case of SCTP, it sends a message with a 64- 
bit nonce (in a HEARTBEAT). 
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One possible approach to do this reachability test would be to 
perform a 3-way handshake for each new address pair that is going to 
be used in an MPTCP connection. While there are other reasons for 
doing this (such as NAT traversal), such approach would also act as a 
reachability test and would prevent the flooding attacks described in 
this section. 


Another type of flooding attack that could potentially be performed 
with MPTCP is one where the attacker initiates a communication with a 
peer and includes a long list of alternative addresses in explicit 
mode. If the peer decides to establish subflows with all the 
available addresses, the attacker has managed to achieve an amplified 
attack, since by sending a single packet containing all the 
alternative addresses, it triggers the peer to generate packets to 
all the destinations. 


6. Hijacking Attacks 
6.1. Hijacking Attacks to the Basic MPTCP 


The hijacking attacks essentially use the MPTCP address agility to 
allow an attacker to hijack a connection. This means that the victim 
of a connection thinks that it is talking to a peer, while it is 
actually exchanging packets with the attacker. In some sense, it is 
the dual of the flooding attacks (where the victim thinks it is 
exchanging packets with the attacker but in reality is sending the 
packets to the target). 


The scenario for a hijacking attack is described in the next figure. 


+------ + +------ + 
| Node | ------------------------- | Node | 
| 1 |IP1 IP2| 2 | 
+------ + /+------ + 
/ 
/ 
/ 
v IPA 
+-------- + 
Attacker 
A 
+-------- + 


An MPTCP connection is established between Node 1 and Node 2. The 


connection is using only one address per endpoint, IP1 and IP2. The 
attacker then launches the hijacking attack by adding IPA as an 
additional address for Node 1. There is not much difference between 


explicit or implicit address management, since, in both cases, the 
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Attacker A could easily send a control packet adding the address IPA, 
either as control data or as the source address of the control 
packet. In order to be able to hijack the connection, the attacker 
needs to know the 4-tuple that identifies the connection, including 
the pair of addresses and the pair of ports. It seems reasonable to 
assume that knowing the source and destination IP addresses and the 
port of the server side is fairly easy for the attacker. Learning 
the port of the client (i.e., of the initiator of the connection) may 
prove to be more challenging. The attacker would need to guess what 
the port is or to learn it by intercepting the packets. Assuming 
that the attacker can gather the 4-tuple and issue the message adding 
IPA to the addresses available for the MPTCP connection, then the 
Attacker A has been able to participate in the communication. In 
particular: 


o Segments flowing from the Node 2: Depending how the usage of 
addresses is defined, Node 2 will start using IPA to send data to. 
In general, since the main goal is to achieve multipath 
capabilities, it can be assumed that unless there are already many 
IP address pairs in use in the MPTCP connection, Node 2 will start 
sending data to IPA. This means that part of the data of the 
communication will reach the attacker but probably not all of it. 
This already has negative effects, since Node 1 will not receive 
all the data from Node 2. Moreover, from the application 
perspective, this would result in a Denial-of-Service (DoS) 
attack, since the byte flow will stop waiting for the missing 
data. However, it is not enough to achieve full hijacking of the 
connection, since part of data will be still delivered to IP1, so 
it would reach Node 1 and not the attacker. In order for the 
attacker to receive all the data of the MPTCP connection, the 
attacker must somehow remove IP1 of the set of available addresses 
for the connection. In the case of implicit address management, 
this operation is likely to imply sending a termination packet 
with IP1 as source address, which may or may not be possible for 
the attacker depending on whether ingress filtering is in place 
and the location of the attacker. If explicit address management 
is used, then the attacker will send a remove address control 
packet containing IP1. Once IP1 is removed, all the data sent by 
Node 2 will reach the attacker and the incoming traffic has been 
hijacked. 


Bagnulo Informational [Page 11] 


RFC 6181 MPTCP Threat Analysis March 2011 


o Segments flowing to the Node 2: As soon as IPA is accepted by Node 
2 as part of the address set for the MPTCP connection, the 
attacker can send packets using IPA, and those packets will be 
considered as part of MPTCP connection by Node 2. This means that 
the attacker will be able to inject data into the MPTCP 
connection, so from this perspective, the attacker has hijacked 
part of the outgoing traffic. However, Node 1 would still be able 
to send traffic that will be received by Node 2 as part of the 
MPTCP connection. This means that there will be two sources of 
data, i.e., Node 1 and the attacker, potentially preventing the 
full hijacking of the outgoing traffic by the attacker. In order 
to achieve a full hijacking, the attacker would need to remove IP1 
from the set of available addresses. This can be done using the 
same techniques described in the previous paragraph. 


A related attack that can be achieved using similar techniques would 
be an MiTM attack. The scenario for the attack is depicted in the 
figure below. 


+------ + +------ + 
| Node | --------------- | Node | 
| 1 |IP1 IP2| 2 | 
iin + \ /+------ + 
\ / 
\ / 
\ / 
v IPA v 
+-------- + 
|Attacker | 
| a | 
+-------- + 
There is an established connection between Node 1 and Node 2. The 


Attacker A will use the MPTCP address agility capabilities to place 
itself as a MiTM. In order to do so, it will add IP address IPA as 
an additional address for the MPTCP connection on both Node 1 and 
Node 2. This is essentially the same technique described earlier in 
this section, only that it is used against both nodes involved in the 
communication. The main difference is that in this case, the 
attacker can simply sniff the content of the communication that is 
forwarded through it and in turn forward the data to the peer of the 
communication. The result is that the attacker can place himself in 
the middle of the communication and sniff part of the traffic 
unnoticed. Similar considerations about how the attacker can manage 
to get to see all the traffic by removing the genuine address of the 


peer apply. 
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6.2. Time-Shifted Hijacking Attacks 


A simple way to prevent off-path attackers from launching hijacking 
attacks is to provide security for the control messages that adds and 
removes addresses by the usage of a cookie. In this type of 
approaches, the peers involved in the MPTCP connection agree on a 
cookie that is exchanged in plaintext during the establishment of the 
connection and that needs to be presented in every control packet 
that adds or removes an address for any of the peers. The result is 
that the attacker needs to know the cookie in order to launch any of 
the hijacking attacks described earlier. This implies that off-path 
attackers can no longer perform the hijacking attacks and that only 
on-path attackers can do so, so one may consider a cookie-based 
approach to secure MPTCP connection results in similar security to 
current TCP. While it is close, it is not entirely true. 


The main difference between the security of an MPTCP secured through 
cookies and the current TCP is the time-shifted attacks. As has been 
described earlier, a time-shifted attack is one where the attacker is 
along the path during a period of time, and then moves away but the 
effects of the attack still remain, after the attacker is long gone. 
In the case of an MPTCP secured through the usage of cookies, the 
attacker needs to be along the path until the cookie is exchanged. 
After the attacker has learned the cookie, it can move away from the 
path and can still launch the hijacking attacks described in the 
previous section. 


There are several types of approaches that provide some protection 
against hijacking attacks and that are vulnerable to some forms of 
time-shifted attacks. A general taxonomy of solutions and the 
residual threats for each type is presented next: 


o Cookie-based solution: As it has been described earlier, one 
possible approach is to use a cookie that is sent in cleartext in 
every MPTCP control message that adds a new address to the 
existing connection. The residual threat in this type of solution 
is that any attacker that can sniff any of these control messages 
will learn the cookie and will be able to add new addresses at any 
given point in the lifetime of the connection. Moreover, the 
endpoints will not detect the attack since the original cookie is 
being used by the attacker. Summarizing, the vulnerability window 
of this type of attacks includes all the flow establishment 
exchanges and it is undetectable by the endpoints. 


o Shared secret exchanged in plaintext: An alternative option that 
is more secure than the cookie-based approach is to exchange a key 
in cleartext during the establishment of the first subflow and 
then validate the following subflows by using a keyed Hashed 
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Message Authentication Code (HMAC) signature using the shared key. 
This solution would be vulnerable to attackers sniffing the 
message exchange for the establishment of the first subflow, but 
after that, the shared key is not transmitted any more, so the 
attacker cannot learn it through sniffing any other message. 
Unfortunately, in order to be compatible with NATs (see analysis 
below) even though this approach includes a keyed HMAC signature, 
this signature cannot cover the IP address that is being added. 
This means that this type of approaches are also vulnerable to 
integrity attacks of the exchanged messages. This means that even 
though the attacker cannot learn the shared key by sniffing the 
subsequent subflow establishment, the attacker can modify the 
subflow establishment message and change the address that is being 
added. So, the vulnerability window for confidentially to the 
shared key is limited to the establishment of the first subflow, 
but the vulnerability window for integrity attacks still includes 


all the subflow establishment exchanges. These attacks are still 
undetectable by the endpoints. The SCTP security falls in this 
category. 


o Strong crypto anchor exchange: Another approach that could be used 
would be to exchange some strong crypto anchor while the 
establishment of the first subflow, such as a public key or a hash 
chain anchor. Subsequent subflows could be protected by using the 
crypto material associated to that anchor. An attacker in this 
case would need to change the crypto material exchanged in the 
connection establishment phase. As a result, the vulnerability 
window for forging the crypto anchor is limited to the initial 
connection establishment exchange. Similar to the previous case, 
due to NAT traversal considerations, the vulnerability window for 
integrity attacks include all the subflow establishment exchanges. 
Because the attacker needs to change the crypto anchor, this 
approach are detectable by the endpoints, if they communicate 
directly. 


6.3. NAT Considerations 


In order to be widely adopted, MPTCP must work through NATs. NATs 
are an interesting device from a security perspective. In terms of 
MPTCP, they essentially behave as an MiTM attacker. MPTCP’s security 
goal is to prevent from any attacker to insert their addresses as 
valid addresses for a given MPTCP connection. But that is exactly 
what a NAT does: it modifies the addresses. So, if MPTCP is to work 
through NATs, MPTCP must accept address rewritten by NATs as valid 
addresses for a given session. The most direct corollary is that the 
MPTCP messages that add addresses in the implicit mode (i.e., the SYN 
of new subflows) cannot be protected against integrity attacks, since 
they must allow for NATs to change their addresses. This rules out 
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any solution that would rely on providing integrity protection to 
prevent an attacker from changing the address used in a subflow 


establishment exchange. This implies that alternative creative 
mechanisms are needed to protect from integrity attacks to the MPTCP 
signaling that adds new addresses to a connection. It is far from 


obvious how one such creative approach could look like at this point. 


In the case of explicit mode, you could protect the address included 
in the MPTCP option. Now the question is what address to include in 
the MPTCP option that conveys address information. If the address 
included is the address configured in the host interface and that 
interface is behind a NAT, the address information is useless, as the 
address is not actually reachable from the other end so there is no 
point in conveying it and even less in securing it. It would be 
possible to envision the usage of NAT traversal techniques, such as 
Session Traversal Utilities for NAT (STUN) to learn the address and 
port that the NAT has assigned and convey that information ina 
secure. While this is possible, it relies on using NAT traversal 
techniques and also tools to convey the address and the port ina 
secure manner. 


7. Recommendation 


The presented analysis shows that there is a tradeoff between the 
complexity of the security solution and the residual threats. After 
evaluating the different aspects in the MPTCP WG, the conclusions are 
as follows: 


MPTCP should implement some form of reachability check using a random 
nonce (e.g., TCP 3-way handshake) before adding a new address to an 
ongoing communication in order to prevent flooding attacks. 


The default security mechanisms for MPTCP should be to exchange a key 
in cleartext in the establishment of the first subflow and then 
secure following address additions by using a keyed HMAC using the 
exchanged key. 


MPTCP security mechanism should support using a pre-shared key to be 
used in the keyed HMAC, providing a higher level of protection than 
the previous one. 


A mechanism to prevent replay attacks using these messages should be 
provided, e.g., a sequence number protected by the HMAC. 


The MPTCP should be extensible and it should be able to accommodate 


multiple security solutions, in order to enable the usage of more 
secure mechanisms if needed. 
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8. 


10. 


11. 


Tis 


E 


Security Considerations 


This note contains a security analysis for MPTCP, so no further 
security considerations need to be described in this section. 
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